home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / ien / ien-153 < prev    next >
Text File  |  1988-12-01  |  25KB  |  767 lines
  1.  
  2.  
  3.  
  4.  
  5.                                                        INDRA
  6.                                                        Working
  7.                                                        Paper
  8.  
  9.  
  10.  
  11.  
  12.  
  13.      INDRA Note 959
  14.      TSIG 4.0
  15.      IEN 153
  16.      29th July 1980
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.      Realization of the Yellow Book Transport Service Above TCP
  28.  
  29.                           C. J. Bennett
  30.  
  31.  
  32.  
  33.  
  34.  
  35.                ABSTRACT:  This  note  defines   an
  36.                enhancement of the service provided
  37.                by the US DoD Standard Transmission
  38.                Control  Protocol  (TCP) sufficient
  39.                to meet the requirements of the  UK
  40.                Network    Independent    Transport
  41.                Service (the Yellow Book).
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.      1. Introduction
  62.  
  63.        This document defines a means of providing the Yellow
  64.      Book  Transport  Service  [1]  above the DARPA Internet
  65.      facilities, in particular TCP [2],  so  that  this  can
  66.      then be used to support other services such as endpoint
  67.      file transfer without requiring UK hosts  to  implement
  68.      the   Internet   family   of   protocols.   It  assumes
  69.      familiarity with both TCP and the Yellow Book.
  70.  
  71.        The basic  approach  taken  is  to  enhance  the  TCP
  72.      service  along the lines suggested for enhancing X25 in
  73.      Annex I of the Yellow Book,  taking  into  account  the
  74.      different  services  provided  by TCP. In addition, the
  75.      note discusses how to integrate Yellow Book TCP so that
  76.      it can run alongside ordinary TCP - an issue the Yellow
  77.      Book ignores for Yellow Book X25.
  78.  
  79.  
  80.      2. Deficiencies of TCP
  81.  
  82.        A comparison of the  services  provided  by  TCP  and
  83.      those  provided  by the Yellow Book reveals that TCP is
  84.      unable to support directly, either in whole or in part,
  85.      the following Yellow Book features:
  86.  
  87.       (i)    The RESET and ADDRESS primitives.
  88.  
  89.       (ii)   The  Yellow  Book  multiple-domain   addressing
  90.              structure.  The TCP address space constitutes a
  91.              single naming  domain  in  Yellow  Book  terms.
  92.              Consequently,  features  involving addressing -
  93.              notably ACCEPT - are inadequately supported  by
  94.              TCP.
  95.  
  96.       (iii)  Much of  the  subsidiary  information  provided
  97.              with  Yellow Book primitives. The fact that the
  98.              source address provided  with  certain  actions
  99.              such  as  DISCONNECT is not provided is again a
  100.              limitation of the global TCP naming domain. The
  101.              Yellow  Book 'Explanatory Text' parameters have
  102.              no corresponding feature in TCP.
  103.  
  104.       (iv)   The closest equivalent to Yellow Book EXPEDITED
  105.              data  - theoretically requiring a priority data
  106.              channel - is  TCP  URGENT  data.  However,  TCP
  107.              URGENT data remains in sequence, and the URGENT
  108.              pointer only marks the end  of  the  data.  Its
  109.              beginning is not delimited.
  110.  
  111.       (v)    The Yellow Book  DISCONNECT  is  a  full-duplex
  112.              close,  whereas  the  TCP  CLOSE  is only half-
  113.              duplex. The TCP RESET is  a  unilateral  close,
  114.              used  in  error  conditions. Connection closure
  115.  
  116.  
  117. Bennett                         1                       INDRA 959
  118.  
  119.  
  120.  
  121.  
  122.  
  123.              provides particularly subtle problems.
  124.  
  125.      Hence in order to provide a Yellow Book  service  above
  126.      TCP  an  enhancement of TCP is necessary. The remainder
  127.      of this document discusses such an enhancement.
  128.  
  129.  
  130.      3. Principles of the Enhancement
  131.  
  132.        The  basic  principles  of  the  enhancement  are  as
  133.      follows:
  134.  
  135.       (i)    Where a TCP function corresponds directly to  a
  136.              Yellow  Book function that TCP function is used
  137.              directly.
  138.  
  139.       (ii)   Where the Yellow Book  function  requires  more
  140.              information  or  action,  the  TCP  function is
  141.              associated with a  TCP  Control  Message  in  a
  142.              defined  way.  This  message is a TCP letter of
  143.              defined  format  containing   the   information
  144.              required.
  145.  
  146.       (iii)  Where there is no TCP  function  even  remotely
  147.              corresponding   to  the  required  Yellow  Book
  148.              function, a control message  is  defined  which
  149.              may  be  used  by  the  source  and destination
  150.              processes if possible,  and  may  be  forwarded
  151.              into  other  transport  domains more capable of
  152.              taking the appropriate action.
  153.  
  154.  
  155.  
  156.      4. The Yellow Book TCP Enhancement
  157.  
  158.      4.1 Distinguishing the Yellow Book TCP
  159.  
  160.        There are several ways a TCP connection  providing  a
  161.      Yellow  Book  service  could  be  distinguished  from a
  162.      normal TCP connection.  These are as follows:
  163.  
  164.       (i)    A single TCP port could be reserved for  Yellow
  165.              Book  service.   Additional  multiplexing could
  166.              then be provided using the  lines  proposed  in
  167.              Annex III of the Yellow Book.
  168.  
  169.       (ii)   A number of TCP ports could be reserved for the
  170.              different  higher level services required, each
  171.              one of which would be defined as including  the
  172.              enhancement defined within this document.
  173.  
  174.  
  175.  
  176. Bennett                         2                       INDRA 959
  177.  
  178.                       Yellow Book above TCP
  179.  
  180.  
  181.  
  182.       (iii)  A  TCP  option  could  be  defined  which  when
  183.              associated   with   a   SYN  would  denote  the
  184.              'enhanced TCP service' option - i.e.  the  data
  185.              stream would be governed by this document.
  186.  
  187.      The first of these possibilities leads  to  unnecessary
  188.      duplication  of  multiplexing  facilities  -  perfectly
  189.      adequate multiplexing is already done within  the  TCP.
  190.      The second is potentially restrictive in that it limits
  191.      the growth  of  future  services,  and  would  probably
  192.      eventually  lead  to the informal adoption of the first
  193.      solution. This notes supports the third course, subject
  194.      to  approval by the DARPA Internet Group. Proposed text
  195.      defining the TCP option, using the format  of  the  TCP
  196.      specification, is as follows:
  197.  
  198.         Enhanced TCP Service
  199.  
  200.           +--------+
  201.           |00000010|
  202.           +--------+
  203.            Kind = 2
  204.  
  205.           This option specifies that the TCP connection
  206.           is  providing  the  data  formats and command
  207.           messages necessary to  support  the  enhanced
  208.           services  offered  by the UK standard Network
  209.           Independent Transport  Service.  This  option
  210.           may  only  be  specified  in  the header of a
  211.           packet which has the SYN bit set  to  1.   If
  212.           the  receiving  process  is unable to support
  213.           this option, the connection should be aborted
  214.           via a RESET.
  215.  
  216.        The adoption of this option does not imply that a TCP
  217.      itself is required to understand the structures of this
  218.      document. It does allow such TCPs to be built. For TCPs
  219.      which  do  not  support  these structures directly, the
  220.      option is effectively a  null  option,  whose  presence
  221.      should be indicated to the receiving process.
  222.  
  223.        Failing the adoption  of  this  facility,  the  first
  224.      choice (of a single reserved port) is supported here.
  225.  
  226.  
  227.      4.2 Identification of TCP Command Messages
  228.  
  229.        Once the connection  is  identified  as  providing  a
  230.      Yellow  Book  TCP  service,  the next problem is how to
  231.      identify TCP Command Messages within the  data  stream.
  232.      The  X25 enhancement made use of the X25 Q-bit for this
  233.  
  234.  
  235. Bennett                         3                       INDRA 959
  236.  
  237.                       Yellow Book above TCP
  238.  
  239.  
  240.  
  241.      purpose, but there is no corresponding function  within
  242.      TCP. The choices are as follows:
  243.  
  244.       (i)    Provision of a  TCP  Q-bit  facility.  This  is
  245.              unlikely   to  occur,  not  least  because  the
  246.              example of XXX  shows  that  it  is  liable  to
  247.              misuse.
  248.  
  249.       (ii)   Further definition of  the  'Enhanced  Service'
  250.              option,  so  that the occurrence of this option
  251.              with a letter specifies that the  letter  is  a
  252.              Command Message.
  253.  
  254.       (iii)  Structuring the data stream itself.
  255.  
  256.      Despite the marginally greater data efficiency  of  the
  257.      second choice, the last choice is supported here, as it
  258.      requires no modification of the TCP user interface.  It
  259.      does, however, require the transmission of a data octet
  260.      which will require a fairly clever  user  interface  if
  261.      extensive buffer copying is to be avoided.
  262.  
  263.        The structure proposed is as illustrated in Figure 1.
  264.      Each TCP letter is prefaced by a single octet, known as
  265.      the TYPE octet. This  takes  a  value  of  0  for  data
  266.      letters  and  a  value  of  1 for command messages. All
  267.      other values are undefined.
  268.  
  269.  
  270.  
  271.             +------+-----  -  -  -  -  -  ------+
  272.             | TYPE |        LETTER BODY         |
  273.             +------+-----  -  -  -  -  -  ------+
  274.                 |
  275.                 |         /
  276.                 |        |  0 = DATA
  277.                 |-------<
  278.                          |  1 = COMMAND
  279.                           \
  280.  
  281.           Figure 1: Letter Structure in Yellow Book TCP
  282.  
  283.  
  284.  
  285.      4.3 Structure of TCP Command Messages
  286.  
  287.        A TCP Command Message is a Yellow Book TCP Letter  of
  288.      TYPE 1.
  289.  
  290.  
  291.  
  292.  
  293.  
  294. Bennett                         4                       INDRA 959
  295.  
  296.                       Yellow Book above TCP
  297.  
  298.  
  299.  
  300.        The first octet of the message  defines  the  COMMAND
  301.      CODE  of  the  message.  These  codes  are  defined  in
  302.      subsequent sections, and have been chosen to correspond
  303.      to the command codes of the X25 Command Messages.
  304.  
  305.        Following the command code is a number of PARAMETERS.
  306.      The  significance  of  these  parameters  is defined by
  307.      their position  in  the  parameter  sequence  for  each
  308.      command; thus no intermediate parameter may be omitted,
  309.      though it may have a null value.  Parameters,  however,
  310.      may  be  omitted  if they and all succeeding parameters
  311.      have null values.
  312.  
  313.        Most parameters have a free field  format.  For  this
  314.      reason  each  parameter  is  constructed of a number of
  315.      FRAGMENTS.  These fragments consist of  a  header  byte
  316.      and  the body of the fragment, which may have a maximum
  317.      length of 127 octets.
  318.  
  319.        The fragment header is a single octet. The high-order
  320.      bit  of  this  octet,  if  set  to 1, declares that the
  321.      current fragment is the last fragment  of  the  current
  322.      parameter.  The  remaining seven bits define the length
  323.      in octets of the current fragment.
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353. Bennett                         5                       INDRA 959
  354.  
  355.                       Yellow Book above TCP
  356.  
  357.  
  358.  
  359.        This structure is summarised in Figure 2.
  360.  
  361.             +-------- - - - - - - - - --------+
  362.             |         COMMAND MESSAGE         |
  363.             +-------- - - - - - - - - --------+
  364.            /                                   \
  365.          /                                       \
  366.        /                                           \
  367.       +------+-------- - - + - - - - - + - - -------+
  368.       | CODE |   PARAM 1   |  .......  |   PARAM N  |   Command
  369.       +------+-------- - - + - - - - - + - - -------+   Structure
  370.             /                \
  371.           /                       \
  372.         /                             \
  373.       /                                   \
  374.      +-------- - - + - - - - - + - - --------+
  375.      |    FRAG 1   |  .......  |   FRAG K    |      Parameter
  376.      +-------- - - + - - - - - + - - --------+      Structure
  377.      |               \
  378.      |                   \
  379.      |                       \
  380.      |                            \
  381.      +--------+------ - - - - - -------+
  382.      | HEADER |          BODY          |    Fragment Structure
  383.      +--------+------ - - - - - -------+
  384.      |          \
  385.      |            \
  386.      |              \
  387.      +-+-+-+-+-+-+-+-+
  388.      | |  C O U N T  |      Header Structure
  389.      +-+-+-+-+-+-+-+-+
  390.       |
  391.       |--- EOP Bit
  392.  
  393.              Figure 2: TCP Command Message Structure
  394.  
  395.        A parameter with a null value  is  represented  by  a
  396.      fragment  header  whose  EOP  bit is set to 1 and whose
  397.      count field is set to 0. The rules governing the syntax
  398.      of  free-field parameters are the same as those defined
  399.      in section 2.7 of the Yellow Book, based on the use  of
  400.      the IA5 character set.
  401.  
  402.        The sole difference between this  structure  and  the
  403.      X25  Command  Message structure is that the count field
  404.      in the fragment header is extended by one  bit  -  this
  405.      bit  is  used  for  a  specific  purpose in X25 CONNECT
  406.      messages which  does  not  arise  with  the  TCP.  This
  407.      doubles  the  maximum  fragment  size.  Because  of the
  408.      similarity of structure the same terminology  has  been
  409.      used,   though   the   term   'fragment'   is  somewhat
  410.  
  411.  
  412. Bennett                         6                       INDRA 959
  413.  
  414.                       Yellow Book above TCP
  415.  
  416.  
  417.  
  418.      unfortunate in the DARPA context through  its  specific
  419.      association with the Internet Datagram Protocol.
  420.  
  421.  
  422.      4.4 Yellow Book Commands and TCP
  423.  
  424.        The following general remarks apply to the  following
  425.      specification:
  426.  
  427.       (i)    All codes are specified as decimal integers.
  428.  
  429.       (ii)   All address fields include the appropriate  TCP
  430.              address      components,      specified      as
  431.              /<NET ID>+<INTERNET HOST ID>+<PORT NO>/,  where
  432.              the  bracketed fields are the character strings
  433.              of  the  octal  representations  of  those  TCP
  434.              fields,  except  where  otherwise noted.  Thus,
  435.              the NIFTP port (octal 10651) at ISIE  (net  12,
  436.              host 1, logical host 0, IMP 64) will be denoted
  437.              by the string:
  438.  
  439.                      /12+200064+10651/
  440.  
  441.  
  442.  
  443.      4.4.1 CONNECT
  444.  
  445.        The  CONNECT  command  message  is  defined  by   the
  446.      following code and parameters:
  447.  
  448.           Code = 16
  449.           Parameter 1: Called Address
  450.           Parameter 2: Calling Address
  451.           Parameter 3: Quality of Service
  452.           Parameter 4: Explanatory Text
  453.  
  454.        This message  will  be  preceded  by  the  usual  TCP
  455.      three-way handshake. Where possible or appropriate, the
  456.      quality of service parameter will be used to select TCP
  457.      quality  of service from the options defined in the TCP
  458.      specification.
  459.  
  460.        The CONNECT message will be the first message sent by
  461.      the  calling party. It will be possible for the calling
  462.      party to initiate  the  transfer  of  data  before  the
  463.      arrival of an ACCEPT message.
  464.  
  465.  
  466.      4.4.2 ACCEPT
  467.  
  468.        The  ACCEPT  command  message  is  defined   by   the
  469.  
  470.  
  471. Bennett                         7                       INDRA 959
  472.  
  473.                       Yellow Book above TCP
  474.  
  475.  
  476.  
  477.      following code and parameters:
  478.  
  479.           Code = 17
  480.           Parameter 1: Recall Address
  481.           Parameter 2: Quality of Service
  482.           Parameter 3: Explanatory Text
  483.  
  484.        This message will be the first message  sent  by  the
  485.      called  party after the three-way handshake, unless the
  486.      call request was rejected (see DISCONNECT,  below).  If
  487.      the  recall  address  and the quality of service do not
  488.      differ from those specified in the CONNECT, the  ACCEPT
  489.      will normally consist of the code octet only.
  490.  
  491.  
  492.      4.4.3 DISCONNECT
  493.  
  494.        The DISCONNECT command  message  is  defined  by  the
  495.      following code and parameters:
  496.  
  497.           Code = 18
  498.           Parameter 1: Reason
  499.           Parameter 2: Address of DISCONNECT Initiator
  500.           Parameter 3: Explanatory Text
  501.  
  502.        The reason parameter  is  a  single  octet  giving  a
  503.      machine-oriented  encoding of the reason the DISCONNECT
  504.      was  initiated.  The  defined  reasons  are  listed  in
  505.      Appendix  B of the body of the Yellow Book. Parameter 2
  506.      is included to cover the case where the DISCONNECT  was
  507.      initiated by some intermediate gateway (where 'gateway'
  508.      is used in the Yellow Book sense).
  509.  
  510.        DISCONNECT will always cause  the  TCP  to  issue  an
  511.      URGENT  call.   On  receipt of a DISCONNECT message, no
  512.      further data may be sent and all data currently  queued
  513.      for  transmission  should  be  flushed if possible.  No
  514.      data  will  be  passed  across  to  the  user  after  a
  515.      DISCONNECT has been issued.
  516.  
  517.        Beyond  this,  the  exact  DISCONNECT  sequence  used
  518.      varies  depending  on  the  state of the connection, as
  519.      follows:
  520.  
  521.       (i)    If the DISCONNECT is being  used  to  reject  a
  522.              CONNECT request, the DISCONNECT message will be
  523.              followed by a TCP RESET. This  will  abort  the
  524.              TCP  connection, flushing all outstanding data.
  525.              No response is  expected.  The  URGENT  pointer
  526.              points to the TCP RESET.
  527.  
  528.  
  529.  
  530. Bennett                         8                       INDRA 959
  531.  
  532.                       Yellow Book above TCP
  533.  
  534.  
  535.  
  536.       (ii)   In  the  normal  case  of   closing   an   open
  537.              connection,   the   DISCONNECT  issued  by  the
  538.              initiator will be followed by a  TCP  FIN.  The
  539.              remote  party  will  respond  with  an optional
  540.              DISCONNECT message accompanied by a FINACK  and
  541.              a  FIN.  The  URGENT  pointer points to the TCP
  542.              FIN.
  543.  
  544.       (iii)  For error terminations,  a  DISCONNECT  message
  545.              should be answered with a TCP RESET. The issuer
  546.              of the DISCONNECT will also issue a  TCP  RESET
  547.              after  a  timeout  period,  if  a RESET has not
  548.              already  been  received.   The  URGENT  pointer
  549.              points to the end of the DISCONNECT message.
  550.  
  551.  
  552.  
  553.      4.4.4 DATA
  554.  
  555.        DATA is sent as a sequence of Yellow  Book  TCP  data
  556.      letters, as defined above.
  557.  
  558.  
  559.      4.4.5 PUSH
  560.  
  561.        The PUSH function is conveyed by use of the  TCP  EOL
  562.      function,  pointing to the data octet at which the PUSH
  563.      was issued.
  564.  
  565.  
  566.      4.4.6 EXPEDITED
  567.  
  568.        The EXPEDITED  command  message  is  defined  by  the
  569.      following code and parameter:
  570.  
  571.           Code = 21
  572.           Parameter 1: EXPEDITED data
  573.  
  574.        EXPEDITED data is accompanied by a TCP URGENT pointer
  575.      pointing to the end of the letter.
  576.  
  577.        It should be noted that this will cause the  receiver
  578.      of  the  URGENT  to  process  all data up to the URGENT
  579.      pointer in 'fast' mode, whether EXPEDITED  or  not.  As
  580.      noted above, TCP has no direct equivalent of a priority
  581.      data channel, but the mechanism  described  allows  the
  582.      preservation of EXPEDITED data so that it may be passed
  583.      as such in subsequent networks.
  584.  
  585.  
  586.  
  587.  
  588.  
  589. Bennett                         9                       INDRA 959
  590.  
  591.                       Yellow Book above TCP
  592.  
  593.  
  594.  
  595.      4.4.7 RESET
  596.  
  597.        The RESET command message is defined by the following
  598.      code and parameters:
  599.  
  600.           Code = 19
  601.           Parameter 1: Reason
  602.           Parameter 2: Address of RESET Initiator
  603.           Parameter 3: Explanatory Text
  604.  
  605.        TCP has no equivalent of the RESET  function  (a  TCP
  606.      RESET  is  something  else entirely). Thus the only TCP
  607.      action taken with a RESET message is  to  accompany  it
  608.      with an URGENT pointer pointing to the end of the RESET
  609.      message.
  610.  
  611.        As with DISCONNECT, the  defined  RESET  reasons  are
  612.      those  listed  in Appendix B of the main portion of the
  613.      Yellow Book. The address parameter is again included to
  614.      cater  for the case where a RESET was initiated in some
  615.      intermediate network.
  616.  
  617.        A RESET may only be issued if the connection is fully
  618.      open  and  there  are no RESETs already outstanding.  A
  619.      RESET message must always be replied  to  with  another
  620.      RESET  message, leaving the connection open, or with an
  621.      error DISCONNECT message followed by a TCP RESET, which
  622.      will  abort  the  connection.   All  data  and  control
  623.      messages, with the exception  of  DISCONNECT,  received
  624.      after  a RESET has been issued and before a RESET reply
  625.      has been received, will be discarded without  informing
  626.      the  user.  In  the  case of DISCONNECT, the connection
  627.      will be considered as  having  closed  in  an  abnormal
  628.      state.   If  a  DISCONNECT  has been issued, a received
  629.      RESET will be ignored.
  630.  
  631.        Where possible the issue of a RESET should cause  the
  632.      sender to flush its transmission buffers.
  633.  
  634.  
  635.      4.4.8 ADDRESS
  636.  
  637.        The  ADDRESS  command  message  is  defined  by   the
  638.      following code and parameters:
  639.  
  640.           Code = 20
  641.           Parameter 1: Address
  642.           Parameter 2: Address Qualifier
  643.  
  644.  
  645.  
  646.  
  647.  
  648. Bennett                        10                       INDRA 959
  649.  
  650.                       Yellow Book above TCP
  651.  
  652.  
  653.  
  654.        The ADDRESS qualifier is  a  single  octet  parameter
  655.      taking one of the values defined in the Yellow Book:
  656.  
  657.           0: The message is passing  towards  the  addressed
  658.           object.
  659.  
  660.           1: The message is passing away from the  addressed
  661.           object.
  662.  
  663.           2: An addressing error has been detected.
  664.  
  665.        There is no  associated  TCP  action  taken  with  an
  666.      ADDRESS message.
  667.  
  668.        The receiver of an ADDRESS message will  perform  the
  669.      appropriate  ADDRESS  transformation  as defined in the
  670.      Yellow Book.
  671.  
  672.        It is recommended that the  ADDRESS  function  should
  673.      not be used.
  674.  
  675.  
  676.      5. Conclusions
  677.  
  678.        One of the difficulties of writing  a  note  such  as
  679.      this  is that it is addressed to several audiences with
  680.      different interests and not necessarily a great deal of
  681.      overlap either in aim or in background.
  682.  
  683.        The immediate audience  is  the  team  at  University
  684.      College  London  who  are  involved  in  implementing a
  685.      'Protocol Convertor' to  make  possible  direct  access
  686.      between  hosts  in  Britain  using  the  CCITT  and  UK
  687.      national standards and the hosts in the US based on the
  688.      DARPA   Internet  standards.  For  this  audience,  the
  689.      document hopefully defines an answer to what will  soon
  690.      be  a  practical  need,  though  it  is  a  matter  for
  691.      continuing debate to what extent the  full  enhancement
  692.      defined here will be implemented.
  693.  
  694.        Within  Britain,  the  wider  audience  aimed  at  is
  695.      centred  on  the Transport Service Implementors' Group.
  696.      For this group, the aim of the document  will  be  well
  697.      understood  -  it  is  defining  a  service enhancement
  698.      similar to the one that is already defined for X25  and
  699.      the  ones  they  are  defining  for  their local campus
  700.      networks. The aim is  to  provide  a  common  transport
  701.      service  for all these systems. They will be unfamiliar
  702.      with the detailed nature of the TCP itself, but this is
  703.      not  particularly  important. The major interest of the
  704.      document  lies  in  the  fact  that  the  system  being
  705.  
  706.  
  707. Bennett                        11                       INDRA 959
  708.  
  709.                       Yellow Book above TCP
  710.  
  711.  
  712.  
  713.      enhanced is not  an  ordinary  local  network,  but  an
  714.      entire   family   of   networks,   and   the  resultant
  715.      enhancement will make possible direct authorised access
  716.      between UK and US hosts. I would also like to point out
  717.      the issue of separating Yellow Book  enhancements  from
  718.      ordinary  uses  of a network service. This issue is not
  719.      addressed by the X25 enhancement specification.
  720.  
  721.        The US Internetwork Group is likewise unfamiliar with
  722.      the  concepts  and details of the Yellow Book Transport
  723.      Service.  For them, the document will be of interest in
  724.      that  it  shows  how  to  coordinate two very different
  725.      approaches to internetworking. The  Catenet,  based  on
  726.      TCP,   can   be   described  as  a  strongly  connected
  727.      internetwork system, with  common  transport  protocols
  728.      and  a  common  address space. The UK Transport Service
  729.      takes an approach based on providing a  common  service
  730.      interface,  which  leads  to  a weakly connected system
  731.      with common service protocols  and  no  common  address
  732.      space.   Within  this  approach,  the  entire  Internet
  733.      system  appears  as  a  single  component  network,  as
  734.      delimited by the TCP and its address space.
  735.  
  736.        Beyond this the document proposes a new  TCP  option.
  737.      For  most existing TCPs this option will effectively be
  738.      a null option which must be signalled to  the  user  at
  739.      call setup time.  However, there is no reason why a TCP
  740.      could not be built which contained the features of this
  741.      note  as  optional  enhancements selectable by choosing
  742.      the option.
  743.  
  744.  
  745.      6. References
  746.  
  747.      [1] - PSS User Forum  Study  Group  Three:  "A  Network
  748.            Independent   Transport   Service"   SG3/CP(80)2.
  749.            February 1980.
  750.  
  751.      [2] - Information  Sciences  Institute:   "Transmission
  752.            Control Protocol" IEN 112. August 1979.
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766. Bennett                        12                       INDRA 959
  767.